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ABSTRACT 

Three days before Christmas 1968, a computer worm was released on a very 
large interrlational DECnet network. The worm reproduced itself artd was 
received on an estimated 6,000 computer nodes worldwide. However, only a 
small percentage of these nodes actually executed the program. The 
computers that successfully ran the program would try to propagate the worm to 
other computer nodes. 

The worm was released onto the DECnet Internet from a computer at a 
university in Svntzertand. Within 10 minutes after it was released, the worm was 
detected on the Space Ph]^cs Analysis Network, or SPAN, which is NASA's 
largest space and Earth science network. Once the source program for the 
worm was captured, a procedural cure, using existing functionality of the 

computer operating systems, was quickly devised and distributed. A 

combination of existing computer security measures, the quick and accurate 
procedures devised to stop coplM of the worm from executing, and the network 
itself, were used to rapidly provkto the cure. These were the main reasons why 
the worm executed on such a small percentage of nodes. 

The purpose behind the worm was to send an electronic mail message to all 
usem on the computer system running the worm. The message was a 
Christmas greetiriig and was signed "Father Christmas." This paper presents an 
overview of the aiialysis of the events concerning the worm based on an 
investigation that was made by the SPAN Secur% Team and provides some 
insight into future security measures that will be taken to handle computer 
worms and viruses that may hit similar networks in the future. 
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INTRODUCTIQM 

Th© Spac© Physics Analysis Natwork, or SPAN [1], has baan an axtramaiy 
raiiabia intamcttional sdantific computar network that has becoma a major 
element in NASA's <^ick reaction capability for supporting many major NASA 
missions over an aight-yaar period [2]. Major features of SPAN are ite ease of 
UM. efficiency, and availability to sdantists oomfecting rasaarch In scientific 
disciplines such as astronomy, astrophysics, cHm^e, Earth, ocean, pianetary, 
life, and solar terrestrial science. 

Currently, SPAN ties together well over 2,800 computers at NASA centers, 
other government agendas, private companies, and universities In the United 
States, with extensions to the European Space Agency's E-SPAN network. 
SPAN utilizes computer-to-computer communications (DECnet p^ocoi) 
allowing mail, binary file transfer, and remote log-on capaUlity. The majority of 
the computers connected to the network are VAX machines running the VMS 
operating system. SPAN is managed by the National Space Science Data 
Center (NSSDC), located at NASA's Goddard Space Rght Center (GSFC). 

SPAN has interconnections with several national and international wide area 
networks such as HEPNET, INFN. THEnet, DAN, GEONET. UARSnet, and 
ASTRONET. All these networks cooperatively manage unique compeer 
DECnet addresses. The nodes from all these networte then form one 
transparent worldwide network called the DECnet Internet. The combined total 
number of computers reachable over the DECnet Internet Is about 12,000. To 
the user, the DECnet Internet operates like one "easy-to-use" network. The 
DECnet Internet, on one hand, has solved Uie problem of transparerxry 
between computers regardless of what DECnet network they are connected to. 
On the other hand, the DECnet Internet provides the connectivity to make one 
network's security problem everyone's concern. 

On December 22,1988, at approximately 17^ EST (eastern standard time), a 
computer worm was rSscovered on SPAN. This worm has been affectionately 
called the "Father Christmas Worm." A computer worm is a program that is self- 
contained and has the abifity fo propagate i^if euxoss a computer network to 
any idle machine. UnHke a virus, a worm does not mocfi^ another program. In 
the case of the Father Christmas Worm, virtually any computer on the DECrret 
internet could have received a copy of the program. However, an individual 
computer may not have the system software configuration that would enable it 
to execute the program (because of the implementation of certain security 
precautions). 

The purpose of this paper is to pro^ride an overview analysis of the events 
concerning the Father Christmas Worm, based on an investigation made by the 
SPAN Security Team. From this investigation it has been determine that th© 
worm was released from a computer (node number 20597;;) at a university in 
Switzerland. Much of this anaiy^ would not have been pebble without the 
extensive help and assistance of the system manager of node 20597;;. 



The Father Christmas Worm was designed to travel quickfy. Estimates are that 
it was copied to over 6,000 computer nodes. However, it is believed to have 
executed on only a fraction of those computers. 


HOW THE WORM wonKPn 

The worm program was named HI.COM. The COM file type In VAXAfMS 
signifies a command file and is usually written in the DEC command ianguage 
(DCL). DCL provides a user with access to operating- and network-level system 
functions on a local or a remote host. 

Rgure 1 provides a graphic overview of how the worm propagated and 
execut^ on other nodes. During execution of the worm. Node A transferred the 
worm file (HI.COM) to Node B. Node B was determined a section of code in 
the worm program that randomly generated node numbers and then checked to 
see if the node was reachabte. Once the transfer of the program was complete 
and Node B had the worm, Node A then would try to direct Node B to execute 
the HI.COM program. 

So long as the worm was executing, it would continue to search out randomly 
reachable computers and try to propagate itself. On the DECnet Internet, 
separate blocks of DECnet addresses are allocated to indivkJuai wide area 
networks that are not confined to geographic regions. The use of randomly 
generated node numbers by the worm program would ensure a worldwide 
distribution across many networks, which would increase its survivability. 

Node A would try to execute the worm on Node B by one of the following two 
methods: 

’ a system level program, called TASK Object 0, is installed 

in a VAX/VMS computer, it will accept and execute commands from another 
. computer. In other words, TASK Object 0 allows task-to-task jobs to be run 
between two computer systems. In the case of the Father Christmas Worm, 
nodes that were following the SPAN security guidelines had TASK Object 0 
disabled and were not able to execute the HI.COM file. In addition, nodes that 
had disabled TASK Object 0 would also not propagate the worm. 

* Usemame/Password Combination - Another way to direct a remote node to 
execute a program (in this case HI.COM) is by providing a legitimate 
usemame/password combination for verification by the remote node. The 
Father Christmas Worm also tried a usemame4)assword combination of 
OECNCT/DECNET. This oofnbinstion of ussmanie/passwoni has stconoty 
been discouraged from use In documentation by ttw D^it^ EQuipment 
Corporation (DEC) and in the SPAN Security Policy and Gukteiines document 


In the example shown in Rgure 1, Node B had TASK Object 0 installed. Node 
A then directed Node B to load HI.COM in memory and, disguising it under the 
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process name MA1L__178DC, begin execution. The renaming of the process 
from HI to MAIL_1780C was done to hide the fact that a foreign program was 
executing. Mail processes execute quite frequently on these computer nodes 
and are easily missed by a system manager monHoring the s^em. Once 
executing on Node B, the worm deleted the file Hi.CX>M that was stored on the 
disk, once again covering its tracks. Next, the worm mailed Node B's welcome 
banner to the remote node/aocount 20597;:PHSOL1DE in Switzerland. This 
action provided the initiator of the worm a record of the nodes diat were able to 
execute the worm program. However, there is no accurate record of the nodes 
that received a copy of the worm but dd not execute it. 

The MAIL_178DC program also went through a series of time checks looking 
for 1988-12-24‘00:00 on the computer clock, if the actual time did not matdi the 
Christmas Eve time, the worm randomly generstted a new computer rrode 
number (Node C in Rgure 1}. if Node C was operationally available over the 
network, then the Node B worm networked the HI.COM file from its memory to 
the new Node C and asked Node C to execute the program. The cycle then 
started all over again. 

If the system ciod( time on Node B (or any node executing the worm) was 
greater than 1988-12-24*00:00, the worm created a listing of all the authorized 
users on that system arKi sent a Christmas greeting to alt those users. The 
Christmas greeting message is shown Figure 2. It is signed "Father 
Christmas.” After sending out the Christmas mail message, the worm then 
deleted the user list it created and stopped execution. 


WORM EVENT TIMELINE 

On December 22,1988, at 16:52 EST, the Father Christmas Worm was 
released from node 20597:: onto the worldwide DECnet Internet The worm 
was first noticed at GSFC by John McMahon, systems manager of ^AN nmto 
CSDR. at approximately 17.-00 EST. some 10 minutes after it had been 
released. After notifying SPAN management and the NASA Science internet 
Project Office (NSlPO), John also contacted GSFC security to register the 
unauthorized access to U.S. (aovemment computers. The wwm command 
procedure Hi.COM was captured at GSFC, as it had been at several other 
locations throughout the network, and the task of analyzing it began. 

The SPAN Security Team sent messages to all SPAN NASA center managers 
warning them about the worm and what action to take to stop it The SPAN 
NASA center managers are responsible for distributing warnings to the remote 
SPAN sites that are directly connected to them. Notice was also sent to 
HEPNET and THEnet representatives. 

NASA personnel at the Jet Propulsion Laboratory sent out a warning mail 
meswge to 20597::SYSTEM on December 22,1988, at 23:30 EST. The 
warning stated that the running of an automat^ command procedure, like 
Ht.COM, was not permitted on SPAN. This message was received but not read. 



since it was very early in the morning in Switzerland and 20597:: was running 
unattended, which is quite common. 

The PHSOUOE account (where the worm started) was again togged into on 
December 23,1988, from 1:58>2:23 EST. During this time, ail the mail 
messages containing the system banners from the systems which successfully 
executed the worm were read and deleted. 

The DECnet Internet line linking 20597:: to the rest of the world was 
disconnected on December 23,1988, at approximately 03:41 EST. This link 
was scheduled to go down for an upgrade to the circuit. The action had nothing 
to do with the worm, but it cfid isolate an active worm on the large local area 
network at the university in Switzerland, where it continued to propagate to the 
local university nodes (see next section). 

During the early Course of trying to stop the worm, several network systems 
personnel, on their own initiative, issued procetkirai pe^hes or cures for the 
worm. It is important to note that, unlike some vims sitijations, no wccine 
software was necessary; a tightening up of existing computer systems security 
features is aU that was needed to prevent a node from executing the Father 
Christmas Worm. The patches distributed were easy to describe and were 
issued by, for example, SPAN, HEPNET, DCA, and the San Diego 
Supercomputer Center personnel. The basic element of all the procedural 
patches were: 

a) Delete/Disable TASK Object 0 

b) Stop Process MAIL_178DC 

c) Delete all copies of HI.COM 

Many of these patches went out on maiDng distribution lists, such as VIRUS-L 
oyer ARPANET (a TCP/IP network). The Father Christmas Worm itself was also 
distributed to everyone on the VIRUS*L maiKng list (by person or persons 
unknown to us). By the end of December 23. the Father Christmas Worm was 
virtually stopp^ on the DECnet Internet In general, procedural patches were 
reasonably good and provided necessary protection against the Father 
Christmas Worm. 

Within several dsqm after the worm incident, the SPAN Security Team received 
full cooperation from the systems manager of node 20597::. The systems 
manager supplied the team with detailed logs and accounting recorcte from his 
system, in February, a detailed report about the Father Christmas Worm was 
completed by the SPAN Security Team and was turned over to the appropriate 
authorities. 



RESULTS OF THE INVESTIGATION 

After carefully reviewing all of the log-in records to the PHSOUDE aooHint in 
conjunction with the system manager of 20597::. it was condiKfed that a user 
coming through a particular terminal server released the worm program. The 
terminal server excesses could have come from one bulking on the campus or 
from existing dial-in modems. The director of the university where node 20597:: 
is located has had every authorized user of the PHSOLIDE account (15 such 
users) sign a non-involvement statement This affidavit stated that these users 
were not responsible for the creation of HI.COM nor ware they responsible for 
the propagation of the worm onto the network. This adion leads the SPAN 
Security Team to the conclusion that the account had been compromised by an 
unknown individual. This conclusion is not too difficult to reafizs, since the 
password on the account was the same as the username. 

The aocountirtg records also show that on December 23, from 1 :S0^:23 EST, 
the PHSOLIDE account was logged into again via the terrrdnal server. Once 
logged on. this user read and deleted alt the computer system breinere from the 
nodes that returned tNs information to the 20957::PHSOLtDE account over the 
eight-hour period after the worm was released. Even though the actual banners 
had been deleted, the network transaction fifos revealed that. TO nodss sent 
their banners to the Switzerland computer. Of the 79, onty 27 of these nodes 
were on SPAN. 

Within an hour after the intruder collected the banners, then deleted them to 
cover his tracks, the DECnet line linking this computer to the rert of the DECnet 
intern^ was disconnected for a scheduled maintenance. At this time the worm 
was still running on node 20957:: arfo continued to randomly select new nodes 
to propagate to. However, the only nodes available to this a^ve worm were 
connected to the local area network at the university. During the next eight 
hours, of the 610 nodes on the local ui^veislty network, the worm executed oh 
46 computers 90 times, with 15 computer nodes executir>g multiple versions of 
the program. 


CLEANUP ACTIVITIES 

A follow-up investigation by the SPAN Security Team several days after the 
worm was released reveaM that over three-quarters of the knovm nodes (79) 
that previously executed the wonn still had TASK Object 0 accessible as before. 
If needed, TAi^ Ob^ 0 perfonns an important function by easily allowing the 
sharing of peripherals in a local environment it was obvious that the deletion 
of TASK Object 0 from the operating system was not a permanent solution to a 
potential security problem. Snce then, the SPAN Security Team has provided 
these nodes with several cUtematIves from which to chose. These procures 
are outiined in a new release of the SPAN Security Policy, Standards, and 
Guideiines [3] document. 


At the University in Switzerland where the worm was initially released, a report 
was written and cfistributed campus-wide to alert the systems managers of the 
seojrity problems they needed to address. Below is a list of the things the 
systems manager of node 20597:: insisted would be dona campus-wide in 
addition to their existing security procedures. 

a) There wculd be no multi-user accounts 

b) Passwords would be required for dial-in access (through modems) 

c) There would be a restricted user list for dial-in access 

d) Additional accounting information would be required for terminal server 
access 

e) Certain Username/Password combinations would not te allowed 

f) A secure solution for providing TASK Object 0 program functionality 
would be implemented 

It is important to point out that, in addition to the above, the first and most 
important practice in providing a rudimentary level of computer security rests 
with users, by their choice of passwords. Strict password control should be of 
prime importance for everyone on a computer system and its assodated 
netvimrks. For SPAN nodes, a new software audit system is available that will 
provide the system manager with toots to rapidly identify many other security 
weaknesses in the system in addition to the ones described above (send mail to 
NCF::Sisson for further details). 


CQNCUUSIQNS 

The Father Christmas Worm has over 150 lines of rran-trivial control language 
code dernonstrating a reasonable understanding of VAXA^MS and the DECnet 
protocol implementation on DECnet networks. It Is obvious from the analysis of 
this event that the individual who released the Father Christmas Worm realized 
what he or she was doing and carefully returned again to the compromised 
node to collect information (system banners) iiKliaating the extent ^ the worm 
on the DECnet Internet. It is also obvious that the perpetrator expected a large 
number of computers to receive and execute worm, ^nce the worm was 
released during the Christmas holiday season when there would have been the 
best chance of a worm executing on unattended VAX machines. In addition, it 
is typically held by computer hacker groups who make a habit of compromising 
the integrity of computer systems that computer systems managers, in general, 
do not implement apprc^riate security procedures and, therefore, are asking for 
unauthorized access to occur. 

It is estimated that half of the 12,000 DECnet internet nodes received the worm, 
but much less than 2 percent of those computers executed HI.COM within the 
first eight hours after the release of the worm. Within minutes after the worm 
was related, a very quick user reaction across the DECnet internet occurred, 
and the situation was immediately taken seriously. Once the source program 
for the worm was captured, a procedural cure, using existing functionality of the 
computer operating systems, was quiddy devised and cfistributed by several 



organizatons that use the netwotfc. A combination of existing computer 
security measures, the quick and acoirate procedures devised to stop the worm 
from executing, and the network itself were the main reasons the worm 
executed on such a small percentage of nodes. 

On Friday, January 13,1989, a worm nearly identical to the Father Christmas 
Worm entered the DEC internal network, called Easynet The private Easynet 
network contains more nodes than the DECnet internet. However, as discussed 
in a recent issue of Digital News [4], aocortfing to DEC the worm was spotted as 
H entered the network, and the s)^em manager "was able to segregate the 
infected system before the worm could spreed.” H is believed that this incident 
was quickly controlled because of the widespread axpc^re and etqierience 
geuned the previous month with the Father Christmas Worm. 

Overall, the impact of the Father Christmas Worm was minimal in an operational 
sense but extensive in the area of strengthening Computer system security'fan 
ongoing activity). A process has been started to fbrmaHze procedures that will 
deal with worms, viruses, and other violations that threaten the DECnet Internet 
in the future. Ksy security personnel have been identified from es^ of the 
major networks in the DECnet Internet, and their responsibliitles are being 
delineated. 

Whatever may be the intention of the authors of computer worms and viruses, if 
these threats are not met head on and dealt with rapidly, the ultimate result may 
be that they destroy the productive working environment that an open network 
provides. 
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Rgure 1: An overview of the major processes of the "Father Chrtelmae Worm * 

In this Nodes A and B are executing the worm program HI.COM. Although 

Node C has a copy the worni, it does not e)«cute the program nor does it partidpate 
in the propagation of the worm because it has implemeri^ certain security measures. 













24-DEC'l988 00:00 


From: 

NODE::Father Christmas 

To: 

You... 

Sub): 

Christmas Card. 

Hi. 



How are ya 71 had a hard time preparing all the presents, it isnt (^te an easy 
job. I'm getting more and mors totters from the chlidrsn eveiy year and it's not 
so easy to get the terrible Rambo*Quns, Tanks and Space Ships up here at the 
Northpoto. But now the good part Is coming. Distributing aH the presents with 
my sleigh and the deers is re^ fun. When I sfide down the chimneys I often find 
a little present oftored by the diildren, or even a ytUe Brandy from the father. 
(Yeah!) Anyhow the chimneys are getting tighter and tighter every year. I think 
i'il have to put my diet on again. And after Christmas I've got my ^ hoBdays;-). 

Now stop computing and have a good time at home ilil 

Merry Christmas and a happy New Year 

Your Father Christmas 


Rgure 2: The Tather Christmas Worm" electronic mail greeting. This messes 
would only be sent to the users on a system executing the worm if it remained 
undetected until December 24, Christmas eve. After this mail message was 
sent, the wonn program would stop executing. 



